home *** CD-ROM | disk | FTP | other *** search
- Path: munta.cs.mu.OZ.AU!fjh
- From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
- Newsgroups: comp.lang.java,comp.lang.eiffel,comp.lang.misc,comp.lang.c++
- Subject: Re: Constness in languages (Re: java weaknesses and peculiararities)
- Date: 3 Feb 1996 16:42:47 GMT
- Organization: Comp Sci, University of Melbourne
- Message-ID: <4f03a8$don@mulga.cs.mu.OZ.AU>
- References: <30FBED5F.28B8@achilles.net> <4dj4t4$a4@kai.com> <4e6dtm$si5@gaia.ns.utk.edu> <9602901.11916@mulga.cs.mu.OZ.AU> <4ej1eo$s7@stc06.ctd.ornl.gov>
- NNTP-Posting-Host: munta.cs.mu.oz.au
-
- mbk@jt3ws1.etd.ornl.gov (Kennel) writes:
-
- >Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
- >> But types also allow you to do more. Using postconditions only allows
- >> you to ensure the constness of references passed to a routine. Using
- >> types also allows you to ensure the constness of references returned
- >> from a routine.
- >
- >Why do you always want to do that? That's putting restrictions on what
- >the caller can do with a thing.
-
- Sure, you don't *always* want to do it, but often it is useful.
- Being able to add restrictions is in general a useful thing.
-
- >The most common use of "const" you want to ensure that the routine didn't
- >do anything nasty behind your back.
- [...]
- >Yes there are other uses for const, but I think those are better
- >handled by regular types.
-
- I don't think so. This has several problems.
-
- One potential problem is that it requires multiple inheritence.
- If a foo is-a bar, then a const-foo is-a const-bar.
-
- const-bar
- / \
- const-foo bar
- \ /
- foo
-
- Note that you want to use implementation inheritence to
- implement this, not just interface inheritence. So if your language
- does not support multiple implementation inheritence, then you will
- have serious trouble.
-
- A more general problem is that it breaks encapsulation: the user of
- `foo' who decides that they need a `const-foo' is in trouble if the
- designer of `foo' didn't foresee that need.
-
- A final drawback is that this technique generally requires lots
- of boring, repetitive coding.
-
- >> >The fundamental difference between pre- and post-conditions is that
- >> >preconditions put restrictions the caller, whereas postconditions
- >> >put restrictions on the callee.
- >
- >> Right. And types can put restrictions on both. Which is exactly what
- >> you want.
- >
- >The example that started this thread was a demonstration of when such
- >a notion had undesirable consequences: forcing a needless massive
- >"reconsting" of a program or preventing "const" from being used in a
- >natural way.
-
- I didn't see that example; perhaps you could repost it or a similar
- example?
-
- >> Anyway, postconditions aren't sufficient, because if you want to pass a
- >> reference to an object which is shared with another thread or which is
- >> stored in ROM) you also need to be able to prevent intermediate
- >> modifications. Types will allow you to do that; postconditions won't.
- >
- >But we already have types: make an interface "NON_MODIFIABLE_FOOBAR"
- >(or use Eiffel's qualified export capability) that says exactly what is
- >and what isn't modifable. I don't know about C++ but in Eiffel or Sather
- >it's perfectly OK to hide modification routines of attributes from some
- >clients via interfaces.
-
- Yes, but doing this manually has all the problems I described above.
-
- >And you have the full power of normal types in an integrated whole
- >instead of the special "const/non-const" cross "user_defined_types".
-
- I agree that making the relationship between const and non-const too
- special is undesireable. It should be as close as possible to the
- relationship between base class and derived class. But I do think
- that "const" is sufficiently useful to warrant special syntactic support.
-
- >> How is the compiler going to know which variables are aliased to which
- >> other ones?
- >>
- >> Are you supposing that the compiler should be required to do global
- >> aliasing analysis? If so, what level of precision of analysis would
- >> you require?
- >>
- >> That seems to me to be a very big problem for your approach.
- >
- >> You are presuming that the compiler has perfect aliasing information
- >> at compile time. But this is not the case in any of the languages
- >> under discussion.
- >
- >Yes, you're right about that. But C doesn't even try, right?
-
- No; but in C/C++, the type system carries around enough information
- to ensure that aliasing analysis is not needed in order to prove
- const-correctness, so the compiler doesn't need to try.
- (That is, it doesn't need to try for the purposes of checking `const';
- alias analysis may still be useful for optimization, of course.)
-
- >I think aliased const modifications would have to be moved to a "warning"
- >as not all could be detectable.
-
- What exactly do you mean by that? Would the compiler warn about every
- assignment that might possibly modify an aliased const? If so, you
- would get far too many spurious warnings; that would not be practical.
-
- Or would the compiler only warn if it was sure an assignment was going
- to modify an aliased const? In that case, the compiler wouldn't be
- able to provide useful guarantees at compile time. The constness
- annotations would be not be much of an improvment over ordinary
- runtime-checked post-conditions.
-
- >> I don't understand. In C++, "constifying" one routine will not require
- >> any changes to its callers either, will it?
- >
- >In the original example it did: you would have had to declare or
- >make something a "const" type if I remember right.
-
- Again, I missed the example, so if you could repost it, I'd be most obliged.
-
- But I don't think there are any problems that couldn't be solved if the
- caller was written correctly; the could be ensured by making `const'
- the default and requiring an explicit `var' for variables, or by
- getting compilers to warn about places where `const' ought to be
- added.
-
- --
- Fergus Henderson WWW: http://www.cs.mu.oz.au/~fjh
- fjh@cs.mu.oz.au PGP: finger fjh@128.250.37.3
-